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ABSTRACT 

The performance of three communications networks to support autonomous multi-spacecraft 
formation flying systems is presented. All systems are comprised of a ten-satellite formation arranged 
in a star topology, with one of the satellites designated as the central or “mother ship. All datais 
routed through the mother ship to the terrestrial network. The first system usre a TCMP over ATM 
protocol architecture within the formation; the second system uses the IEEE 802.11 protoco 
architecture within the formation; and the last system uses both of the previous architectures with a 
constellation of geosynchronous satellites serving as an intermediate point-of-contact between the 
formation and the terrestrial network. The simulations consist of file transfers using either the File 
Transfer Protocol (FTP) or the Simple Automatic File Exchange (SAFE) Protocol. The results 
compare the IP queuing delay, and IP processing delay at the mother ship as well as application-level 
round-trip time for both systems. In all cases, using IEEE 802.11 within the formation yields less 
delay. Also, the throughput exhibited by SAFE is better than FTP. 

INTRODUCTION 

Multi-spacecraft formation flying systems enable an improvement in mission performance while 
reducing operating costs [1]. These systems are comprised of multi-satellite fleets and their associated 
ground stations, which together achieve the following objectives. First, satellites in the same 
formation can provide redundancy in the event of a node failure. Second, multiple satellites in a 
formation can be used to increase the overall system capacity and throughput, and finally, multiple 
satellites in a formation enable larger spatial coverage as well as prolonged temporal availability. It is 
anticipated that the use of autonomous multi-satellite formation flying systems will be cost-effective to 
implement and more reliable than single-satellite counterparts [2][3]. 

Current research on the concept of autonomous formation flying satellite systems emphasizes the 
techniques necessary to perform control of formation location and geometry, which is accomplished 
with the exchange of command, control, and navigation information between spacecrafts in the 
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formation. Researchers at Stanford University have demonstrated the effective use of Carrier-Phase 
Differential GPS (CDGPS) to obtain very precise (cm level) estimations of formation location and 
relative geometry [4], Additionally, several other papa’s have been published in the literature 
concerning the precise control of the spacecrafts within a multi-satellite formation. The literature 
indicates that the distances between the satellites in a formation should be controlled to within a 
centimeter in the near-term, i.e., the next five years, and to within a fraction of a centimeter for 
missions in the next ten years. The Autonomous Formation Flyer (AFF) Sensor, for example, borrows 
technology from the Global Positioning System (GPS) to maintain the precise control of the spacecraft 
within the Deep Space 3 (DS3) mission [5]. Similarly, a Collective Intelligence (COIN) has been 
devised to control the constellations of communications satellites [6]. From reviewing the literature, it 
is clear that the precise control of the spacecraft within a formation flying system is very important for 
several planned missions, and the degree of precision is a function of the intended mission. 


While a mechanism to perform formation control and navigation is necessary, a suitable inter- 
spacecraft communications system (ISC) is necessary to support the exchange of command, control, 
and navigation information as well as scientific data. The ISC system must also support formation 
adaptation to dynamic mission conditions [7], 

In order for formation flying satellites to accomplish a greater level of autonomy, future missions will 
require the spacecrafts within the formation to exhibit a higher level of functionality. This 
functionality can be accomplished by incorporating the Internet Protocol (IP) into die protocol 
architecture that is utilized by each spacecraft within the formation. Incorporating IP into the ISC 
system provides several advantages, some of which include the following. IP allows the infusion of 
commercially developed, technology, and provides interoperability with the terrestrial Internet. Also, 
IP could provide multicasting and broadcasting capabilities, which may prove useful for missions 
involving satellites in formation flight. 

This paper presents the simulated performance analysis of three networks to support the inter- 
spacecraft communication needs for autonomous multi-spacecraft formation flying systems. As 
mentioned, an important objective of this research is to investigate the concept of “Internet node in the 
sky” as it applies to formation flying satellite systems. Therefore, from a networking perspective, the 
formation flying system has to be interoperable with the terrestrial Internet. The basic simulated 
protocol architecture is TCP/IP over ATM. The first system uses a TCP/IP over ATM protocol 
architecture within the formation; the second system uses the IEEE 802.11 protocol for 
communication within the formation; and the last system uses both of the previous architectures 
with a constellation of geosynchronous satellites serving as an intermediate point-of-contact 
between the formation and the terrestrial network. The performance of the three systems is 
compared for some representative file transfers using either FTP or SAFE. 

SAFE PROTOCOL 

The SAFE protocol operates in the application layer of the protocol suite and was designed to function 
independently of the underlying transport protocol. Therefore SAFE can use UDP, rather than TCP, as 
the transport protocol [8]. Since UDP is insensitive to propagation delays, SAFE avoids the well- 
documented problems associated with using TCP over satellite links. Additionally, SAFE does not 
waste any time establishing a connection, since UDP is connection-less. However, UDP does not 
provide flow control, reliable transfer of data and congestion control; therefore, SAFE must provide 
these services in the application layer. 

The File Transfer Protocol (FTP) from the TCP/IP suite provides a service comparable to SAFE, but 
FTP must be used in conjunction with TCP. SAFE, as mentioned, is not bound to any particular 
transport protocol since all the reliability, flow control and congestion control mechanisms are 
provided in the application layer. As a result, SAFE can take advantage of the changes (such as the 
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CCSDS-SCPS suite) that are being devised to improve network performance over satellite and space 
communication links. 

SAFE uses the client-server network configuration where the server node hosts the source data, called 
the primary file, and the client attempts to create a secondary file which is an exact replica of the 
primary file. The client sends requests to the server, and the server passively waits for a request to 
arrive from the client; the request initiates the transfer from the server to the client. If a request from 
the client extends beyond the end of the primary file, the server will set an end-of-file (EOF) flag 
within the reply packet. When the client detects the EOF flag, it will wait a prescribed period of time 
before requesting additional data beyond the last advertised EOF offset. Since the client periodically 
sends requests for more data, the secondary file at the client is an exact replica of the primary file. 

As mentioned earlier, since SAFE operates in the application layer and uses UDP as the transport 
protocol, the SAFE protocol must provide the functions of TCP. The flow control, reliable data 
transfer and congestion control mechanisms used by SAFE are very similar to that of TCP Reno, and it 
implements the slow start, congestion avoidance, fast retransmit and fast recovery algorithms of TCP. 
In order to maximize the utilization of network bandwidth, SAFE sends requests asynchronously in 
that multiple requests can be outstanding at any time. To correlate the pending requests with the 
received segments, the SAFE client associates a message ID to each request that is sent to the SAFE 
server, and the server will return this message ID within the reply packet. Thus, the client can match 
requests to replies and reorder the segments, if necessary, before writing the data to the secondary file. 

NETWORK CONFIGURATION ! 

The topology of the first formation flying simulation scenario is shown in figure 1. In this 
configuration, we consider a formation flying system consisting of ten satellites. These satellites are in 
a LEO orbit with the orbital characteristics of the International Space Station (ISS). One satellite in 
the formation is designated as the “mother ship,” and all communication between the satellites and the 
terrestrial network takes place via the mother ship. The terrestrial network is comprised of 12 ground 
stations distributed around the Earth. These ground stations are connected in a star topology with the 
White Sands Ground Terminal, New Mexico, at the center. Communication between the formation 
and ground stations, and among the ground stations is at OC-3. 

Using the client-server paradigm, the satellites in the formation are simulated to function as servers 
and there is a single client at White Sands. The performance of this network is analyzed by simulating 
FTP file transfers. As an alternative to FTP, which uses TCP at the transport layer, the SAFE protocol, 
which operates over UDP, was also simulated. A set of comparative performance characteristics for 
these two protocols, FTP over TCP and SAFE over UDP, is included. 


10 Satellite LEO Formation 

TCP/IP ov«rATM at OC4 



Figure 1-Network Configuration I 
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All spacecrafts within the formation are simulated to behave as servers, and files are transferred from 
each spacecraft in the formation through the mother ship to the terrestrial network. The spacecraft 
servers can use either FTP or the SAFE protocol in the application layer of the protocol suite. All 
terrestrial sites consist of routers that utilize an IP over ATM protocol architecture, and data received 
by a terrestrial site is forwarded to the White Sands Ground Terminal. The simulated White Sands 
Ground Terminal consists of a radio transceiver, which connects to a router, and all terrestrial sites in 
the network are connected to the WSGT router. The terrestrial client resides in the WSGT subnet and 
can use either FTP or the SAFE protocol in the application layer. The protocol architecture for 
Configuration I is shown in figure 2. 
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Figure 2-Configuration I Protocol Architecture 


NETWORK CONFIGURATION II 

The second simulation scenario differs from the first in that the IEEE 802.11 protocol architecture is 
used for communication, at 11 Mbps, between the satellites in the formation. The rationale for 
simulating IEEE 802.11 for a formation of satellites is that from a networking perspective, the 
formation can be viewed as a wireless LAN. Also, precise distances between satellites can be easily 
maintained. All other features of this configuration such as the number of satellites, mother ship, 
orbital characteristics, locations of ground stations and topology of the terrestrial network are identical 
to the first scenario. This enables us to evaluate the impact of using IEEE 802. 1 1 for communication 
within the formation by comparing the same performance measures. Also, we compare the throughput 
of FTP/TCP with SAFE/UDP. Network Configuration II is illustrated in figure 3, and the protocol 
architecture is shown in figure 4. 


10 Satellite i£0 Formation 
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Figure 4-Configuration H Protocol Architecture 
NETWORK CONFIGURATION III 

The last configuration uses the topology and medium access techniques of the previous two network 
configurations. This time, however, a geosynchronous earth orbit (GEO) satellite constellation serves 
as an intermediate transfer point between the formation and the terrestrial sites. The advantage of this 
approach is that three GEOs can provide almost global coverage, and, therefore, the number of ground 
stations can be reduced. A disadvantage of this approach is the long propagation delay associated with 
using satellites in geosynchronous orbit. A comparison of the TCP/IP over ATM protocol 
architecture, as in the first network scenario, to the IEEE 802. 1 1 protocol architecture, as in the second 
network scenario, is performed Network Configuration 133 is illustrated in figure 5. 

The orbital characteristics of the simulated geosynchronous satellites match those of TDRS-3, TDRS- 
4, and TDRS-5 and are located at 275° W longitude, 41° W longitude, and 174° W longitude, 
respectively. Due to the almost global coverage provided by the geosynchronous satellites, the 
number of ground stations is reduced to just two - the Guam Remote Ground Terminal (GRGT) and 
the White Sands Ground Terminal. The protocol architecture for the simulated satellites, however, 
differs from that of the TDRSS satellites. The node architecture for Network Configuration IE is 
shown in figure 6. 

10 Satellite LEO Formation GEO Constellation 



TCP/IP over ATM at 004 


Figure 5-Network Configuration 111 
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Figure 6 -Configuration III Protocol Architecture 


RESULTS 

In order to compare the performance of Network Configuration I to Network Configuration II, the IP 
queuing delay and IP processing delay were observed at the central ship router, additionally, a 
comparison of application-level round-lrip time is presented. Table 1 compares the IP queuing delay, 
IP processing delay and round-trip time for all three network configurations. Files of 100 kB were 
transferred at constant intervals of 300 sec for simulations of Configurations I and II,. For 
Configuration ffl, due to the complexity of the simulation scenario, smaller files of 10 kB were 
transferred at intervals of 300 sec. In all cases, using IEEE 802.11 for communication within the 
formation yields better results. 


Table I-Comparison of Network Configurations 
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The performance of the SAFE protocol was compared to FTP for all the configurations, using 
throughput as the performance metric. All simulations of FTP used TCP with a 64 kB receive window 
with the SACK option, window scaling option and the fast retransmit/fast recovery algorithms 
enabled. 


Table 2 - Average throughput (bps) comparison of SAFE and FTP for Configurations I and H 


i — i 

SAFE 

FTP 

Configuration 1 

10 kB 

34,05 

32.2 

100 kB 

199.35 

179.07 

1 MB 

3087.27 

2399.66 

Configuration II 

10 kB 

48.64 

34.32 

100 kB 

288.51 

208.36 

1 MB 

3211.12 

2580.07 
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Table 3-Throughput comparison at WSGT for Configuration III 


1 — 1 


Throuahout from GEO-2 (bos) 


325.05 

279.49 

BSBBBI 

321.29 

260.72 

fcfJMMMSlI 

289.81 

234.29 


286.23 

227.26 


CQNCLVS IQ3S 

All formation flying network configurations considered, which utilized the IEEE 802.11 protocol 
within the formation, yield lower queuing delay, processing delay, and application-level round-trip 
time. Since the 802.11 medium access technique allows stations to contend for access to a shared 
medium, the number of collisions is reduced, and hence delay is decreased and throughput is 
increased. Since the TCP/IP over ATM network configuration utilized a FDMA technique to gain 
access to the mother ship router, multiple stations can be communicating simultaneously. As a result, 
greater queuing delay and processing delay is required at the network layer of the mother ship router. 
This increase in delay results in lower throughput and increased round-trip time. 

As shown in the preceding tables, SAFE exhibited higher throughput than FTP for all network 
configurations. Current research suggests that the contribution of the data-link layer protocol to the 
performance of application-layer protocols is not well understood and deserves further research. As 
the simulation results indicate, both the ATM protocol and the IEEE 802.1 1 protocol have an influence 
on the performance of SAFE and FTP. Despite this influence, SAFE still exhibits greater throughput 
than FTP, even though the difference is much less significant. 
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